Can we avoid the type check using polymorphism?

I propose:

To add a new method: testFilter validateFailures: results.

It should do:

(self resultsContainUnexpectedFailuresOrErrorsFor: results)
		ifTrue: [ MTTestsWithErrorsException signal ]

in the superclass and nothing in MTRedTestFilter.

Then this method should

MTAnalysis >> initialTestRun [ 

	| results |
	results := testCases collect: [ :aTestCase | aTestCase run ].
	testFilter validateFailures: results. "Throws error or not based on filters"
	testCases := testFilter filterTests: testCases
]

Another option is to throw the exception in the filterTests:, but I prefer the other option, it's cleaner and easier to implement.

I agree here, the class comparison is not nice :).
If tomorrow we subclass it or add a class with similar behavior, this code will change many many times.
Better to delegate to the filter as @PalumboN says.

About the two options, doing it inside filterTests: or validateFailures:, I'm ok with any.

Now looking at the code I'm wondering, does it do what it should? :D
The thing is:

• if I have 10 tests out of which 1 is red
• with the red test filter we should have 9 tests for the analysis, and 1 test ignored

Which means that:

1. the filter cannot be just on the "test references" but on the test + result => I see that the tests have a lastResult, so this is ok!
2. If, after running the filters, (and whatever the filter we have) there were broken tests, we should throw the exception => This means we can get the code of the error outside the filter, right?

Anyways, I see you already implemented it, I think my proposal could be an enhancement for later ^^. I propose we open an issue for it

I'm not sure I understood exactly what you meant, but if what I did is ok I guess I can fix the merge so we can integrate the pr, and we can discuss about your idea tomorrow @guillep ?